View AN282_8357739.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

rev. 0.1 5/06 copyright ? 2006 by silicon laboratories AN282 AN282 usb m ass s torage d evice r eference d esign p rogrammer ' s g uide 1. introduction among the usb device classes natively supported by popular operating systems, the usb mass storage device (msd) class is one of the most widely supported device cl asses. a usb device that supports this class can use the built-in drivers provided by the operatin g system, without the need to install or maintain any cust om device drivers. the usb msd reference desi gn utilizes this widespread support by providing device firmware for silicon laboratories usb microcontrollers that complies with the msd class specification. this usb msd reference design programmer's guide describes in detail the vari ous components of the device firmware. the usb-msd-rd reference design kit user's guide includes demonstratio n instructions and information about the kit contents. 2. usb msd reference design hardware overview the msd reference design hardware consists of two boards - c8051f340-tb target board and cf, sd, mmc memory expansion board (ab5). these are contained in the kits c8051f340dk and usb-msd-rd, respectively. see the usb-msd-rd user's guide for details on the c ontents of these kits. figu re 1 shows these two boards connected via the expansion connector. figure 2 show s a block diagram with the connections between the hardware components. refer to the u sb-msd-rd user's guide for detailed pi n connections, sche matic, and bill of materials of the evaluation board. figure 1. c8051f340-tb target board connected to ab5 expansion board relevant devices this application note app lies to the following devices: c8051f340, c8051f341, c8051f342, c8051f343, c8051f344, c8051f345, c8051f346, c8051f347
AN282 2 rev. 0.1 figure 2. usb msd rd hardware block diagram sd / mmc memory card c8051f340-tb pc spi parallel interface compactflash memory card (for example app) (for msd) usb rs232 ab5 memory expansion board
AN282 rev. 0.1 3 3. usb msd reference design firmware overview the usb msd rd firmware consists of many distinct blocks that work together. the ov erall system architecture is shown in figure 3. the code space usage ratio of the different blocks is shown in figure 4. figure 3. usb msd rd system architecture usb function controller mass storage device scsi sector server file system media access example application adc sd / mmc memory card c8051f340 usb mixed signal mcu rs232 transceiver usb temp. sensor push buttons uart external hw peripherals spi compact flash memory card usb host controller rs232 serial port c8051f340-tb target board ab5 memory expansion board driver stack driver stack windows explorer or other application hyperterminal pc usb msd data flow example app. data flow components used only for usb msd data flow example app. components that can be customized file system api serving the example app. shared media access components
AN282 4 rev. 0.1 figure 4. usb msd firmware code space usage on the c8051f340 the firmware is designed such that the refe rence design can be used in one of two ways: mass storage device mode (connected to the pc via usb) independent embedded system mode (connected to the pc via rs232 serial interface). in msd mode, the device appears as a usb mass stor age device on the pc. this mode uses the firmware components 'usb', 'mass storage device', 'scsi', 'secto r server', and 'media access'. in embedded system mode, the example application can accept commands vi a a uart command interpreter shell, and perform appropriate functions. in this mode, a rs232 serial co nnection is made between the 'f340 target board and the pc. this mode uses an external rs232 transceiver, some on-chip hardware peripherals (temp. sensor, adc, uart), and the firmware components 'example application' , 'file system', 's ector server', and 'media access'. each component is explained in deta il in the following sections. the usb-ms d-rd user's guide contains step-by- step instructions that demonstrat e both the modes of operation. 4. usb msd rd firmware components 4.1. usb msd rd me dia access firmware the usb msd rd includes firmware to access sd/mmc and compactflash cards. in a typical application where only one type of interface is needed, the unnecessary media access firmware can be removed to save code space. also, some parts of this media access firmware might need to be modified to fit the end application. for example, the pins that are assigned to the spi peripheral might need to be changed to accomodate other system requirements. 4.1.1. compactflash interface firmware the compactflash (cf) interface firmware is the low-level interface that allows the rest of the system to access a cf memory card. the cf card is accessed by the firmware using a parallel interface that consists of an 8-bit data bus, a 3-bit address bus, and 6 control signals. a cf card is connected to the 'f340 device port pins as described in section ?2. usb msd reference design hardware overview?. after a device reset, the init_cf function is called by the sector server. if this detects a card, then a call to identify_drive is made to ge t the size information of the card. the read_sector and write_sector functions are then used for data transfers. the compactflash media access functions are described belo w. there is typically no need to call any of these functions directly from the applicatio n-level firmware because the sector server layer encapsulates them. when designing new hardware, these functions may need to be modified to suit the new hardware connections. usb / msd / scsi (3.9 kb) 6% sector server (1.1 kb) 2% used (23.9 kb) 38% sd / mmc media access (2.1 kb) 3% cf media access (0.7 kb) 1% compiler libraries / misc (5.1 kb) 8% example application (5.1 kb) 8% file system (5.9 kb) 9% available free space (39.1 kb) 62%
AN282 rev. 0.1 5 4.1.1.1. init_cf description: initializes a co mpactflash memory card. supported devices: c8 051f340/1/2/3/4/5/6/7 module: f34x_msd_cf_basic_functions.c prototype: char init_cf (void) parameters: none. return value: 0, if initialization was successful. cf_no_card, if no card was detected. 4.1.1.2. identify_drive description: reads the card identif ier from a compactflash card. supported devices: c8 051f340/1/2/3/4/5/6/7 module: f34x_msd_cf_basic_functions.c prototype: char identify_drive (char* buffer) parameters: 1. buffer-pointer to a memory location for returning the card identifier information. return value: none. 4.1.1.3. read_sector description: reads a 512-byte block from a compactf lash card starting at the location specified by address . the block is copied to the memory location pointed to by buffer . supported devices: c8 051f340/1/2/3/4/5/6/7 module: f34x_msd_cf_basic_functions.c prototype: char read_sector (unsigned long address, char* buffer) parameters: 1. address-starting address of the 512-byte block in the cf card. 2. buffer-pointer to a memory location where the data will be copied to. return value: 0, if the read operation was successful. cf_no_card, if no cf card was detected. errorcode, otherwise. 4.1.1.4. write_sector description: write a 512-byte block to a compactfla sh card starting at the location specified by address . the block is copied from the memory location pointed to by buffer to the cf card. supported devices: c8 051f340/1/2/3/4/5/6/7 module: f34x_msd_cf_basic_functions.c prototype: char write_sector (unsigned long address, char* buffer) parameters: 1. address-starting address of the 512-byte block in the cf card. 2. buffer-pointer to a memory location where the data will be copied from. return value: 0, if the wr ite operation was successful. cf_no_card, if no cf card was detected. errorcode, otherwise.
AN282 6 rev. 0.1 4.1.2. sd/mmc interface firmware the sd/mmc interface firmware is the low-level interface that allows the rest of the system to access secure digital (sd) and multimediacard (mmc) memory cards. sd/mmc cards use spi fo r communication in 4-wire mode. a sd/mmc card is connected to the 'f340 device port pins as described in section ?2. usb msd reference design hardware overview?. after a devi ce reset, the sector server checks if a cf card is present as described in section 4.1.1. if no cf card is detected, then mmc_flash_ init is called to check if a sd/mmc card is present. the sd/mmc media access functions are described below. th ere is typically no need to call any of these functions directly from the application-level firmware because the sector server layer encapsulates them. when designing new hardware, these functions may need to be modi fied to suit the new hardware connections. 4.1.2.1. mmc_flash_init description: initializes a sd/mmc memo ry card. this calls th e internal function spi_init to initialize the spi hardware, examines the operating condit ions register (ocr) to ensure that the device has been initialized correctly, and also determines the size of the card by reading the card specific data register (csd). supported devices: c8 051f340/1/2/3/4/5/6/7 module: f34x_msd_mmc.c prototype: void mmc_flash_init (void) parameters: none. return value: none. 4.1.2.2. mmc_flash_block_read description: reads a 512-byte block from a sd/mmc card starting at the location specified by address . the block is copied to the memory location pointed to by pchar . supported devices: c8 051f340/1/2/3/4/5/6/7 module: f34x_msd_mmc.c prototype: unsigned int mmc_flash_block_read (unsigned long address, unsigned char* pchar) parameters: 1. address-starting address of the 512-byte block in the sd/mmc card. 2. pchar-pointer to a memory loca tion where the data will be copied to. return value: 0, if the read operation was successful. card response code, otherwise. 4.1.2.3. mmc_flash_block_write description: write a 512-byte block to a sd/mmc card starting at the location specified by address . the block is copied from the memory location pointed to by wdata to the cf card. supported devices: c8 051f340/1/2/3/4/5/6/7 module: f34x_msd_mmc.c prototype: unsigned char mmc_flash_block_write (unsigned long address, unsigned char *wdata) parameters: 1. address-starting address of the 512-byte block in the cf card. 2. wdata-pointer to a memory location where the data will be copied from. return value: 0, if the wr ite operation was successful. card response code, otherwise.
AN282 rev. 0.1 7 4.2. sector server the tasks and capabilities of the sector server are listed below: encapsulates lower-level cf and sd/mmc media access f unctions, so that those functions do not need to be called from the applic ation-level firmware. detects and initializes the memory card on startup. reads and validates the boot sector of the memory card. checks for a block size of 512 bytes, fat16 filesystem, and a boot sector si gnature of 0xaa55 (little endian). reads and stores a global copy of details about the memory card such as the number of fat copies, the number of root directory entries, the number of sectors, and the size of each fat. maintains one 512-byte scratch buffer that is used by the entire system to read or write blocks of data. handles multiple fat copies by keeping them in sync with each other. transaction commits and rollbacks are not supported because of this approach, i.e. transact ions are always committed, and cannot be rolled back. supports memory cards with capacity up to 4 gb. th is restriction is imposed by the fat16 filesystem. maintains a global disk map. this is an overview of where each fat copy begins and ends, where the root directory is located, and where the file data area begins . see table 1 for an example sector server view of a 32 mb mmc card. the embedded file system api and the scsi command in terpreter encapsulate the sector server functions. so, there is typically no need to call any of the sector server functions directly from the application-level firmware. because of this, these functions are not explained here in detail. instead, a list of sector server functions with brief explanations is presented in table 2. table 1. sector server view of a 32 mb mmc card (fat16 filesystem) mmc block numbers scsi block numbers used for: number of blocks size 0 non-existent partition table 1 512 b 1..31 non-existent not used 31 15.5 k 32 0 boot record 1 512 b 33..275 1..243 1 st fat copy 243 122 kb 276..518 244..486 2 nd fat copy 243 122 kb 519..550 487..518 root directory 32 16 kb 551..end 519..end file data 62000+ 30+ mb
AN282 8 rev. 0.1 4.3. usb low-level interface the usb descriptor is an important component of the usb low-level interface. when a usb device is plugged into a usb host, usb enumeration is initiated, during which usb descriptors are request ed by the host to determine the capabilities and requirements of the device. the information cont ained in the descriptor allows the host to load the appropriate device drivers and allocate power to the device, if requested. see "appendix a?msd rd usb descriptor details" on page 20 for mo re information about the usb descripto rs used in the usb msd rd firmware. the tasks and capabilities of the usb low-level interface are listed below: loads data into the in endpoint fifo. reads data from the out endpoint fifo. handles bus conditions usb suspend, resume and reset. sends a stall when the host sends an unsupported command. handles the usb standard req uests that are listed below: get_status clear_feature set_feature set_address get_descriptor get_configuration set_configuration get_interface set_interface the usb low-level interface functions are internal functions to the msd rd, and need not be called directly from the application-level firmware. please refer to the module "f34x_msd_usb_isr.c" for the functions and their descriptions. table 2. sector server functions function name description module: f34x_msd_sect_serv.c sect_init initializes and validates the memory card. sect_validate checks the validity of the memory card boot record. sect_sectors returns the number of sectors of the current memory card. sect_print prints memory card type and size. sect_read reads one sector into the scratch buffer. sect_write writes one sector from the scratch buffer. sect_write_multi_fat writes changes to the 1 st fat copy in the 2 nd fat copy as well, thus keeping both the fat copies in sync. sect_root_dir returns the first se ctor of the root directory. sect_root_dir_last returns the last sector of the root directory. sect_file_data returns the first sector of file data. sect_fat1 returns the first sector of the 1 st fat sect_fat2 returns the first sector of the 2 nd fat
AN282 rev. 0.1 9 4.4. msd class command interpreter the mass storage device class command interpreter communicates directly with the hardware usb data endpoints (in and out) that are managed by the usb low-level interface code. no te that the usb control endpoint traffic is handled by the usb low-level interfac e, and is not seen by the msd class command interpreter. the 'msd class - bulk only transport ' specification defines two structures that are used for reliable command transport and status transport. they are described below: 4.4.1. command block wrapper (cbw) cbw is defined as a packet containing a command block a nd associated information. see figure 5 for the format of this structure. 4.4.2. command status wrapper (csw) csw is defined as a packet containing the status of a co mmand block. see figure 5 for the format of this structure. table 3. command block wrapper (cbw) format 76543210 0?3 dcbwsignature = 0x43425355 4?7 dcbwtag 8?11 dcbwdatatransferlength 12 bmcbwflags (including direction bit) 13 reserved (0) bcbwlun 14 reserved (0) bcbwcblength (1..16) 15?30 cbwcb (contains scsi command) table 4. command status wrapper (csw) format 76543210 0?3 dcswsignature (= 0x53425355) 4?7 dcswtag (=identical as dcbwtag) 8?11 dcswdataresidue (=dcbwdatatransferlength ? number of bytes processed) 12 bcswstatus (=good, fail or phase error)
AN282 10 rev. 0.1 4.4.3. command interp reter state machine the command interpreter implements a simple state machin e that is very similar to the command/data/status flow shown in figure 5. in the state machine implementation, the 'data - in' and 'data - out' stages in this figure have been combined into one state. figure 5. msd class - command/data/status flow msd_ready: the state machine is in this state most of the time. in this stat e, the command interpreter receives data via the data out endpoint and checks whether it is a valid and meaningful cbw. if it is determined to be a valid and meaningful cbw, then it moves to the next state, which is msd_data. msd_data: in this state, the valid cbw is sent to the scsi block for processing. depending on the contents of the cbw (direction bit in bmcbwflags), either a data -in or a data-out transfer happens. then, the state machine transitions to the next state. msd_status_transport: in this state, the good/faile d/phaseerror status and the amount of unprocessed bytes is returned in a csw. after this state, the state machine reverts to the msd_ready state. the state machine is implemented as one function, which is described below. ready command transport (cbw) status transport (csw) data ? in (to host) data ? out (from host)
AN282 rev. 0.1 11 4.4.4. msd_step description: the msd class command in terpreter is implemented as a state machine in this function. this function should be call ed periodically from the main loop. for the usb msd rd firm- ware, the interval should be less than 3 ms to keep the data transfer at the highest possi- ble level. increasing the callin g interval over 3 ms will lower the data transfer speed. the determination of the 3 ms interv al involves the timing of th e low-level media access func- tions. so, the best interval should be reevaluated if any modifications are made to those functions. supported devices: c8 051f340/1/2/3/4/5/6/7 module: f34x_msd_msd.c prototype: void msd_step (void) parameters: none. return value: none. refer to section ?5. mass stor age device mode oper ation? for an illustration of how the msd block communicates with the other firmware components.
AN282 12 rev. 0.1 4.5. scsi command interpreter small computer system interface - 2 (scsi-2) is a standard primarily used by hard disk drives and optical drives that defines an i/o bus for interconnecting computers and peripherals. the usb msd class specification is written such that scsi commands can be emb edded inside the msd class structures cbw and csw. this allows flash- based memory cards to be connected via usb and appear as disk drives within the operating system. the usb msd rd implements a scsi command interpreter to process and respond to the scsi commands sent by the msd block. this is responsible for the parsing and handli ng of 10 different scsi commands as listed in table 5. unknown commands are also properly handled. table 5. scsi commands, codes, and responses scsi command scsi code response scsi_test_unit_ready 0x00 ?passed? scsi_inquiry 0x12 code const byte scsi_standard_inquiry_data[36]= { 0x00, // peripheral qualifier & device type 0x80, // removable medium 0x05, // version of the standard (5=spc-3) 0x02, // no normaca, no hisup, data format=2 0x1f, // no extra parameters 0x00, // no flags 0x80, // basic task management supported 0x00, // no flags 's','i','l','a','b','s',' ',' ', 'm','a','s','s',' ', 's','t','o','r','a','g','e' }; scsi_mode_sense_6 0x1a code const byte scsi_mode_sense_6[4]= { 0x03,0,0,0 // no mode sense parameters }; scsi_start_stop_unit 0x1b ?passed? scsi_prevent_allow_medium _removal 0x1e ?passed? scsi_read_capacity_10 0x25 byte scsi_read_capacity_10[8]={ 0x00,0x00,0xf4,0x5f, // last block address 0x00,0x00,0x02,0x00 // block length }; scsi_read_10 0x28 read a number of sectors from the memory card and send those via the usb in bulk endpoint. scsi_write_10 0x2a receive a numbe r of sectors via the usb out bulk endpoint and write these sectors to the mem- ory card. scsi_verify_10 0x2f ?passed? (this command is used when the host pc formats the filesystem).
AN282 rev. 0.1 13 the msd class command interpreter ca lls the scsi command interpreter whenever a valid and meaningful cbw is received from the host. after processing the command, the scsi comm and interpreter is responsible for setting scsi_status and status_residue to appropriate values. scsi_status can be set to one of three values: passed (0), failed (1), or phase error (2). scsi_residue indicates how many byte s of data have not been processed. 4.6. embedded file system interface this firmware component is unique compared to the other bl ocks because this is the only one that is solely used by the application firmware when the device is in 'embedded s ystem mode', and not at all when it is in 'mass storage device mode'. this component provi des the application firmware with an api to the fat16 file system. this interface is commonly referred to as a "stream i/o interface" because of the us e of functions like fopen, fread, and fclose. note that long file names (lfns) are not supported by this api functions. abbreviated lfns (abcdef~1.txt etc) can be used in place of lfns. the api functions are described in the section below. 4.6.1. filesys_init description: initializes variables that ar e used for navigation over directories. supported devices: c8 051f340/1/2/3/4/5/6/7 module: f34x_msd_file_system.c prototype: void filesys_init (void) parameters: none. return value: none. 4.6.2. write_current_dir description: sends the current working directory path via the uart. supported devices: c8 051f340/1/2/3/4/5/6/7 module: f34x_msd_file_system.c prototype: void write_current_dir (void) parameters: none. return value: none. 4.6.3. chngdir description: changes the current working directory. supported devices: c8 051f340/1/2/3/4/5/6/7 module: f34x_msd_file_system.c prototype: byte chngdir (char* dirname) parameters: 1. dirname-pointer to a memory location that contains the directory name. return value: 0, if the directory does not exist. 1, if the directory change was successful.
AN282 14 rev. 0.1 4.6.4. mkdir description: creates a new directory. supported devices: c8 051f340/1/2/3/4/5/6/7 module: f34x_msd_file_system.c prototype: byte mkdir (char* dirname) parameters: 1. dirname-pointer to a memory location that contains the directory name. return value: 0, if the dire ctory was created successfully. directory_exists, if a directory by the specified name already exists. no_place_for_directory, if there is no space to create a directory. 4.6.5. rmdir description: removes the specified directory. the cont ents of the directory (files, subdirectories) are also deleted. supported devices: c8 051f340/1/2/3/4/5/6/7 module: f34x_msd_file_system.c prototype: byte rmdir (char* dirname) parameters: 1. dirname-pointer to a memory location that contains the directory name. return value: 1, if the directory was successfully removed. 0, otherwise. 4.6.6. fcreate description: creates a new file with the specified name. supported devices: c8 051f340/1/2/3/4/5/6/7 module: f34x_msd_file_system.c prototype: static byte fcreate (find_info* findinfo, char* filename) parameters: 1. findinfo-pointer to a structure with details about the file. 2. filename-pointer to a memory location that contains the filename. return value: 1, if the file was created successfully. 0, otherwise.
AN282 rev. 0.1 15 4.6.7. fopen description: opens a file in one of three modes - re ad (r), write (w), appen d (a). in write/append modes, if the specified filename does not exist, it is created. in write mode, if the specified file exists, it is overwritten. supported devices: c8 051f340/1/2/3/4/5/6/7 module: f34x_msd_file_system.c prototype: int fopen (file* f, char* filename, char* mode) parameters: 1. f-pointer to file structure 2. filename-pointer to a memory location that contains the filename. 3. mode-pointer to a memory location that contains the file open mode. return value: 1, if file was opened successfully. 0, otherwise. 4.6.8. fread description: reads the specified number of bytes from a file. supported devices: c8 051f340/1/2/3/4/5/6/7 module: f34x_msd_file_system.c prototype: unsigned fread (file* f, byte* buffer, unsigned count) parameters: 1. f-pointer to file structure 2. buffer-pointer to a memory location where the data will be copied to. 3. count-the maximum number of bytes to read from the file. return value: number of bytes read from the file. 4.6.9. fwrite description: writes the specified number of bytes to a file. supported devices: c8 051f340/1/2/3/4/5/6/7 module: f34x_msd_file_system.c prototype: unsigned fwrite (file* f, byte* buffer, unsigned count) parameters: 1. f-pointer to file structure 2. buffer-pointer to a memory location where the data will be copied from. 3. count-the number of bytes to write to the file. return value: number of by tes written to the file.
AN282 16 rev. 0.1 4.6.10. feof description: checks whether the specif ied file's current position pointer has reached the end of the file. supported devices: c8 051f340/1/2/3/4/5/6/7 module: f34x_msd_file_system.c prototype: int feof (file* f) parameters: 1. f-pointer to file structure return value: 0, if the file's current position pointer has not reached the end of the file. 1, if the file's current position pointer has reached the end of the file. 4.6.11. fclose description: closes a file. supported devices: c8 051f340/1/2/3/4/5/6/7 module: f34x_msd_file_system.c prototype: void fclose (file* f) parameters: 1. f-pointer to file structure return value: none. 4.6.12. fdelete description: deletes a file in the current working directory. supported devices: c8 051f340/1/2/3/4/5/6/7 module: f34x_msd_file_system.c prototype: int fdelete (char* name) parameters: 1. name-pointer to a memory location that contains the file name. return value: 1, if the f ile was deleted successfully. 0, otherwise. 4.6.13. format_disk description: formats a disk to the fat16 file system . note that the disk should have an existing parti- tion for this to work. warning: calling this function will erase all the data on the disk. supported devices: c8 051f340/1/2/3/4/5/6/7 module: f34x_msd_format_disk.c prototype: void format_disk (void) parameters: none. return value: none.
AN282 rev. 0.1 17 5. mass storage device mode operation when the device is in mass storage device mode, the following blocks are used. see figure 3 for the connections between the blocks. usb low-level interface mass storage device cla ss command interpreter scsi command interpreter sector server media access firmware the interactions between the usb, msd, scsi, and se ctor server blocks are shown in figure 6 and figure 7. figure 6. mass storage device mode operation (host to device) figure 7. mass storage device mode operation (device to host) usb msd scsi sect-serv cbw csw usb out scsi rx scsi status scsi residue sect write usb msd scsi sect-serv cbw csw usb in scsi rx scsi status scsi residue sect read
AN282 18 rev. 0.1 6. embedded sy stem mode operation when the device is in the embedded system mode, the following blocks are used. see figure 3 for the connections between the blocks. app. specific hardware (rs232 transceiver) on-chip hardware peripherals (t emp. sensor, adc, and uart) application firmware file system api sector server media access firmware see the usb msd user's guide for demonstration instructions and a list of commands supported by the example application's uart-based command interpreter shell. for detailed information about the implementation of the example application, refer to the source files in the so ftware package that accompanies this application note. 7. customizing usb msd rd firmware the firmware components included in this reference design can be classified into four categories based on how they will be used in an end applicat ion. this classification shows whic h components you sh ould modify when designing an application that is based on this reference design. 1. firmware components that are typically used without any modifi cation - usb, msd, scsi, and sector server fall in this category. 2. firmware components that need modification based on the end application's hardware design - media access firmware falls in this category. 3. firmware components that can be customized with company and/or product information - the following fall in this category: a. scsi device name that is returned on a scsi_inquiry command b. usb descriptor parameters that are returned on usb standard requests: vid, pid, and serial number. 4. firmware components that are fully customizable - the example application and all its related functions fall in this category . you can either modify the provided example code to fit your application needs, or you can create an application from scratch using the file system api fu nctions listed in section 4.6.
AN282 rev. 0.1 19 8. references the following specifications/standards were used as references for this design. [1] universal serial bus specification, revision 2.0, december 21, 2000. [2] universal serial bus mass storage device class bu lk-only transport, revision 1.0, september 31, 1999 [3] scsi architecture model - 3 (sam-3), revision 9, september 12, 2003 [4] scsi block commands - 2 (sbc-2), revision 10, september 13, 2003 [5] scsi primary commands - 3 (spc-3), revision 17, january 28, 2004 [6] multimedia commands - 4 (mmc-4), revision 2d, september 2, 2003 [7] cf+ and compactflash, revision 3.0 [8] mmc system specification, revision 3.31
AN282 20 rev. 0.1 a ppendix a?msd rd usb d escriptor d etails the usb descriptor used by the usb msd rd is availa ble in the module 'f34x_msd_usb_descriptor.c'. the descriptor has been written based on the information from the 'usb msd bulk-only transport' specification. the salient points about this descriptor are listed here: device descriptor the device descriptor field must have a unique serial number t hat is at least 12 digits. a unique serial number on a usb device maintains the same device devnode as a user moves the device from one usb port to another. this unique devnode ensures that properties like icons, policie s, and drive letters associated with the device are not reset when the device is moved to a different usb port or when a second device with the same vid/pid/rev is added to the system. this is set to "0078976543 210" in this design, and can be customized. interface descriptor binterfaceclass is set to 0x08. this indicates that the device belongs to the usb mass storage device class. binterfacesubclass is set to 0x06 (scsi transparent m ode). microsoft supports 0x 02 for atapi cd-rom, 0x05 for atapi removable media, and 0x06 for generic scsi media. binterfaceprotocol is set to 0x50 (bulk-only transport).
AN282 rev. 0.1 21 a ppendix b?usb h ost d etails when the usb msd rd is connected to the pc via a usb cable, it appears as a usb mass storage device. there is no need to install any drivers because the operating s ystem has built-in class driver s. in the case of the usb msd rd, three windows built-in drivers are aut omatically loaded. they are listed here: table 6. drivers loaded by windows device driver stack driver generic volume file system silabs mass storage usb device disk.sys usb mass storage device usbstor.sys
AN282 22 rev. 0.1 c ontact i nformation silicon laboratories inc. 4635 boston lane austin, tx 78735 email: mcuinfo@silabs.com internet: www.silabs.com silicon laboratories, silicon labs, and usbxpress are trademarks of silicon laboratories inc. other products or brandnames mentioned herein are trademarks or registered trademarks of their respective holders. the information in this document is believed to be accurate in all respects at the time of publ ication but is subject to change without notice. silicon laboratories assumes no responsibility for errors and om issions, and disclaims responsibi lity for any consequences resu lting from the use of information included herein. ad ditionally, silicon laboratorie s assumes no responsibility for the functioning of und escribed features or parameters. silicon laboratories reserves the right to make changes without further notice . silicon laboratories makes no wa rranty, rep- resentation or guarantee regarding the suitability of its products for any particular purpose, nor does silicon laboratories as sume any liability arising out of the application or use of any product or circuit, and s pecifically disclaims any and all liability, including wi thout limitation conse- quential or incidental damages. silicon laborat ories products are not designed, intended, or authorized for use in applications intended to support or sustain life, or for any other application in which the failure of t he silicon laboratories product could create a s ituation where per- sonal injury or death may occur. should buyer purchase or us e silicon laboratories products for any such unintended or unauthor ized ap- plication, buyer shall indemnify and hold silicon laboratories harmles s against all claims and damages.

▲Up To Search▲

Price & Availability of AN282

	To Download AN282 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .